Skip to content

Conversation

@fortnern
Copy link
Member

@fortnern fortnern commented Oct 27, 2025

2 remaining test failures seemingly related to cmake. Adding this PR in the hopes that someone better at cmake than me can help.

Closes #5315


Important

Change default file format to 1.8 across various tests and examples, updating file creation and access logic accordingly.

  • Behavior:
    • Default file format version changed to 1.8 in H5Pfapl.c.
    • Updated file creation and access to use 1.8 format in h5ex_g_compact.c and test_file_image.c.
    • Set earliest file format in multiple test files including cache_tagging.c, dtypes.c, and links.c.
  • Tests:
    • Modified expected output in tools/test/misc/expected/*.ls files to reflect new file format locations.
    • Adjusted test logic in test_file_image.c and cache_tagging.c to accommodate format changes.
  • Misc:
    • Added comments and TODOs for future format testing in test_file_image.c.
    • Minor variable renaming for clarity in test_file_image.c.

This description was created by Ellipsis for 85332ed. You can customize this summary. It will automatically update as commits are pushed.

fortnern and others added 3 commits October 27, 2025 15:27
Co-authored-by: ellipsis-dev[bot] <65095814+ellipsis-dev[bot]@users.noreply.github.com>
@fortnern fortnern requested a review from epourmal as a code owner October 27, 2025 21:18
@byrnHDF
Copy link
Contributor

byrnHDF commented Oct 27, 2025

There were no CMake changes so need to see the failing instance.

@byrnHDF
Copy link
Contributor

byrnHDF commented Oct 27, 2025

One of the first workflows failing had two test failures:
The following tests FAILED:
640 - H5IMPORT_SUB-DUMP-tall_fp32-CMP (Failed)
645 - H5IMPORT_SUB-DUMP-tall_i32-CMP (Failed)

@byrnHDF
Copy link
Contributor

byrnHDF commented Oct 27, 2025

Current CI CMake 4 arm64 Workflows / MacOS Clang-Release-- has these tests failing:

The following tests FAILED:
2707 - JUnit-TestH5Fparams (Failed)
2708 - JUnit-TestH5Fbasic (Failed)
2727 - JUnit-TestH5P (Failed)
2729 - JUnit-TestH5Pfapl (Failed)
Errors while running CTest

@byrnHDF
Copy link
Contributor

byrnHDF commented Oct 27, 2025

Searching the logs for the failing tests shows this for Fparams java test:
JUnit version 4.13.2
2599: .testH5Fis_accessible_null
2599: .testH5Fcreate_null
2599: .testH5Fflush_local
2599: .testH5Fget_info
2599: E.testH5Fmount_null
2599: .testH5Fcreate
2599: .testH5Fflush_global
2599: .testH5Funmount_null
2599: .testH5Fclose_negative
2599: .testH5Fopen_null
2599:
2599: Time: 0.064
2599: There was 1 failure:
2599: 1) testH5Fget_info(test.TestH5Fparams)
2599: java.lang.AssertionError: H5.H5Fget_info: java.lang.AssertionError: expected:<2> but was:<0>
2599: at org.junit.Assert.fail(Assert.java:89)
2599: at test.TestH5Fparams.testH5Fget_info(TestH5Fparams.java:218)
2599:
2599: FAILURES!!!
2599: Tests run: 10, Failures: 1

@fortnern
Copy link
Member Author

There were no CMake changes so need to see the failing instance.

One of the first workflows failing had two test failures: The following tests FAILED: 640 - H5IMPORT_SUB-DUMP-tall_fp32-CMP (Failed) 645 - H5IMPORT_SUB-DUMP-tall_i32-CMP (Failed)

This was the failure that I thought was cmake related - those two test files were missing. It's possible that my working directory was messed up. I deleted it and tried again and saw the same two tests fail, but it's possible I didn't notice they failed for a different reason, as Jordan saw the same two tests fail with an expected output mismatch. I fixed the mismatch so they should work now. Do they still fail?

@fortnern fortnern dismissed stale reviews from brtnfld and mattjala via 4451a5e October 29, 2025 17:18
@hyoklee
Copy link
Member

hyoklee commented Oct 29, 2025

@fortnern, FYI - I see 2 VFD test failures with HL & CPP & all debugging & v16 API options on Ubuntu-24.04:
https://my.cdash.org/viewTest.php?onlyfailed&buildid=3167967
I hope it's not related to your change.

I configured HDF5 with HL, CPP, and 1.6 API, and cannot reproduce these failures with: HDF5_TEST_DRIVER="multi" ./cpp_testhdf5 or HDF5_TEST_DRIVER="family" ./cpp_testhdf5

What do you mean by "all debugging"?

Is this CDash test testing my branch? This hasn't been merged to develop yet.

Yes. You can easily duplicate it using my GH Action script:
lin.yml

@jhendersonHDF
Copy link
Collaborator

cannot reproduce these failures with: HDF5_TEST_DRIVER="multi" ./cpp_testhdf5 or HDF5_TEST_DRIVER="family" ./cpp_testhdf5

You may need to use HDF5_DRIVER="multi" ./cpp_testhdf5 / HDF5_DRIVER=family" ./cpp_testhdf5 instead. HDF5_TEST_DRIVER is mostly meant for tests that use h5_fileaccess() to get a FAPL (sort of a leftover from Autotools) where HDF5_DRIVER applies to all FAPLs by default.

@fortnern
Copy link
Member Author

These failures appear to be preexisting bugs that were exposed by the change, and not simply tests expecting the oldest file format. I'm trying to track them down but it might take some time.

mattjala
mattjala previously approved these changes Oct 30, 2025
@fortnern
Copy link
Member Author

The 2 failures with multi were due to issues with the test code. The family failure was due to weirdness in how the family driver handled the user block. My position is the family driver shouldn't handle it at all, but I'm willing to hear other opinions. Either way the way it handled it before was wrong.


### Fixed problems with family driver and user block

When using a user block with the family driver, the driver would inappropriately subtract the user block size for each member file when calculating member eoas. This could cause a failure when an addresse overflowed the calculated eoa. The driver would also add the user block size when returning the eof. Modified the family driver to not consider the user block, as it is handled by the H5FD layer. The user block now spans the first x bytes of the family array, for example a 4 KiB user block with 3 KiB member size will take up the entire first member and the first 1 KiB of the second. This may cause compatibility issues with preexisiting family files with user blocks, though the way it worked before was inconsistent if it worked at all.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
When using a user block with the family driver, the driver would inappropriately subtract the user block size for each member file when calculating member eoas. This could cause a failure when an addresse overflowed the calculated eoa. The driver would also add the user block size when returning the eof. Modified the family driver to not consider the user block, as it is handled by the H5FD layer. The user block now spans the first x bytes of the family array, for example a 4 KiB user block with 3 KiB member size will take up the entire first member and the first 1 KiB of the second. This may cause compatibility issues with preexisiting family files with user blocks, though the way it worked before was inconsistent if it worked at all.
When using a user block with the family driver, the driver would inappropriately subtract the user block size for each member file when calculating member eoas. This could cause a failure when an address overflowed the calculated eoa. The driver would also add the user block size when returning the eof. Modified the family driver to not consider the user block, as it is handled by the H5FD layer. The user block now spans the first x bytes of the family array, for example a 4 KiB user block with 3 KiB member size will take up the entire first member and the first 1 KiB of the second. This may cause compatibility issues with preexisting family files with user blocks, though the way it worked before was inconsistent if it worked at all.


### Fixed problems with family driver and user block

When using a user block with the family driver, the driver would inappropriately subtract the user block size for each member file when calculating member eoas. This could cause a failure when an addresse overflowed the calculated eoa. The driver would also add the user block size when returning the eof. Modified the family driver to not consider the user block, as it is handled by the H5FD layer. The user block now spans the first x bytes of the family array, for example a 4 KiB user block with 3 KiB member size will take up the entire first member and the first 1 KiB of the second. This may cause compatibility issues with preexisiting family files with user blocks, though the way it worked before was inconsistent if it worked at all.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
When using a user block with the family driver, the driver would inappropriately subtract the user block size for each member file when calculating member eoas. This could cause a failure when an addresse overflowed the calculated eoa. The driver would also add the user block size when returning the eof. Modified the family driver to not consider the user block, as it is handled by the H5FD layer. The user block now spans the first x bytes of the family array, for example a 4 KiB user block with 3 KiB member size will take up the entire first member and the first 1 KiB of the second. This may cause compatibility issues with preexisiting family files with user blocks, though the way it worked before was inconsistent if it worked at all.
When using a user block with the family driver, the driver would inappropriately subtract the user block size for each member file when calculating member eoas. This could cause a failure when an address overflowed the calculated eoa. The driver would also add the user block size when returning the eof. Modified the family driver to not consider the user block, as it is handled by the H5FD layer. The user block now spans the first x bytes of the family array, for example a 4 KiB user block with 3 KiB member size will take up the entire first member and the first 1 KiB of the second. This may cause compatibility issues with preexisting family files with user blocks, though the way it worked before was inconsistent if it worked at all.

try {
// Create file FILE1
file1 = new H5File(FILE1, H5F_ACC_EXCL);
file1 = new H5File(FILE1, H5F_ACC_TRUNC);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why the change in file access mode here?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The test is creating a new file. H5F_ACC_EXCL causes it to fail if the file already exists, which is what was happening. It was failing silently before, but with the 1.8 format it causes issues due to a fapl mismatch - see #5954

Copy link
Collaborator

@jhendersonHDF jhendersonHDF Oct 30, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see. Fine either way, though previously the issues with this test involved the fact that it left a file open unintentionally and also forgot to delete it, so I wonder if that isn't the case here as well.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is at least partly due to it simply using HDremove() to remove the test files, which obviously doesn't work with the family file driver. Something that should be fixed for sure, but not within the scope of this PR

Copy link
Contributor

@mattjala mattjala left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Address typos

@github-project-automation github-project-automation bot moved this from To be triaged to In progress in HDF5 - TRIAGE & TRACK Oct 30, 2025
mattjala
mattjala previously approved these changes Oct 30, 2025
@fortnern
Copy link
Member Author

We talked with Quincey about the family driver changes and he agreed with this approach.

jhendersonHDF
jhendersonHDF previously approved these changes Oct 30, 2025
@fortnern fortnern dismissed stale reviews from jhendersonHDF and mattjala via 4914415 October 30, 2025 19:26
@lrknox
Copy link
Collaborator

lrknox commented Oct 30, 2025

Matt's review was dismissed by the commit of a typo fix in CHANGELOG.md

@lrknox lrknox merged commit 5e03b3a into HDFGroup:develop Oct 30, 2025
176 of 177 checks passed
@github-project-automation github-project-automation bot moved this from In progress to Done in HDF5 - TRIAGE & TRACK Oct 30, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Status: Done

Development

Successfully merging this pull request may close these issues.

Adjust default low bound for file format version

8 participants